Bien que l'on m'ai donné comme sujet principal, l'intégration de 
fonctionnalités de QoS au sein de routeurs, une fois ma documentation sur la 
manière de mettre en œuvre cette qualité de service, j'ai appris par la suite 
que pour l'instant seuls les parefeux des routeurs des clients sont crées sur 
FWBuilder or comme il m'a été demandé de baser au maximum la gestion de la QoS 
sur FWBuilder après que j'en ai expliqué les possibilités de la dernière 
version, j'ai donc du réecrire les parefeux des routeurs de la société afin de 
permettre par la suite la mise en place de QoS sur ceux-ci.\\

Le fait de devoir réecrire ces règles de parefeux de SuseFirewall2
\footnote{SuseFirewall2: Logiciel de configuration de parefeu de la distribution
OpenSuse} vers 
FWBuilder m'a pris beaucoup de temps mais m'a aussi permis de comprendre plus 
profondément le fonctionnement de FWBuilder qui même s'il semble facile à 
utiliser au premier abord se révèle relativement complexe lorsqu'il s'agit de 
transférer une configuration d'un parefeu comportant une trentaine de tunnels 
OpenVPN ainsi que plusieurs interfaces réseaux avec la gestion d'une DMZ et 
parfois de plusieurs réseaux distant derrière le même tunnel.\\

J'en ai ainsi appris beaucoup sur les règles de parefeux, la façon de les 
définir et l'importance de l'ordre dans lequel ces règles sont définies.\\

La configuration d'un parefeu SuseFirewall2 se fait dans un fichier à éditer 
directement avec un éditeur de texte. Ce fichier comporte des règles qui ne 
sont pas toujours très bien documentées, comportant même des erreurs dans les 
explications originales présentes au dessous des règles (notamment concernant
la NAT).\\
La configuration d'un parefeu sous FirewallBuilder en revanche se fait en mode
graphique et offre plus de possibilités que les fichiers de SuseFirewall2. 
Cependant, bien que l'interface soit assez agréable, elle manque encore 
d'ergonomie notamment au niveau du \emph{drag\&drop} pour placer les éléments 
sur la grille de règles et l'impossibilité d'utiliser des raccourcis clavier 
pour copier - coller des éléments d'une règle à une autre ou encore de 
sélectionner plusieurs éléments dans les règles en place.\\

Ce travail m'a donc pris beaucoup de temps, ce qui ne m'en a pas laissé 
suffisament pour mettre en œuvre réellement de la QoS sur ces routeurs.\\
J'ai cependant laissé une notice explicative sur la façon de mettre en œuvre 
cette QoS sur le forum de la société.\\

Voici un exemple de règles crées avec FWBuilder:\\

\begin{figure}[H]
	\centering
	\includegraphics[scale=0.4]{texdata/images/fwb_rules.png}
        \caption{Exemple de règles crées sur FWBuilder}
\end{figure}

L'énorme avantage de FWBuilder ne réside pas réellement, selon moi, dans
l'interface graphique mais essentiellement dans la possibilité de gérer 
un ensemble de parefeu depuis un seul fichier généré par FWBuilder et 
contenant l'ensemble des réseaux et machines utilisées dans les règles 
des différents parefeux.\\

Les réseaux, routeurs, postes, … sont ainsi crées dans une bibliothèque
qui permet leur utilisation au sein de plusieurs parefeu qui peuvent être
de nature différente (Systèmes d'exploitation, architectures, … différents).\\

\begin{figure}[H]
	\centering
	\includegraphics[scale=0.4]{texdata/images/fwb_multiFW.png}
        \caption{Exemple de fichier FWBuilder contenant plusieurs parefeux}
\end{figure}

Nous pouvons voir sur cette capture plusieurs parefeux configurés dans le 
même fichier objet. De plus le fichier créer par FWBuilder, avant la 
compilation qui crée un script éxécutable, est un fichier \emph{XML}
\footnote{XML: Extensible Markup Language, language de balisage extensible} 
respectant une \emph{DTD}\footnote{DTD: Document Type Définition, fichier 
donnant la structure à suivre d'un fichier XML}, fwbuilder.dtd ce qui permet 
en cas de besoin de créer un autre programme pour traiter des cas particuliers
ou tout simplement pour s'abstraire à l'interface graphique de FWBuilder.

\subsection{Travail effectué avec FWBuilder}

J'ai crée via FWBuilder, un fichier d'objets comprenant la configuration de 
plusieurs des parefeux de la société ainsi que la définition des hôtes, 
réseaux et services accessibles depuis la société. Depuis cette configuration,
il est ainsi possible de mettre à jour les différents parefeux du site.\\

Lors de la première tentative de migration, il y a eu un problème, le parefeu
bloquait tout même les communications en local (ping localhost) et renvoyait
\emph{Operation not permited}. Ce problème étant bloquant et n'ayant pas 
trouvé de solution évidente, nous avons provisoirement rétablis l'ancien 
routeur. 
Après plusieurs heures passés à revérifier la configuration dans FWBuilder, à 
passer en revue les règles et toutes les options et après de veines recherches 
sur Internet, j'ai fini par trouver la solution, il s'agissait de cocher la
case \emph{top ruleset} associé à l'objet règles du parefeu, sans cette option
activée, celui-ci refuse tout avant même d'ajouter les règles. Les règles sont
donc présentes mais ignorées.\\

\subsection{Migration effective du routeur principal}

Lors de la deuxième tentative de migration, tout s'est déroulé sans problème,
les deux ou trois éléments manquants ont très vite été mis en place. 
Il s'agissait en fait de quelques exceptions qui ont été enlevées durant la 
mise au point du parefeu puisque la plupart étaient devenues inutiles.\\

Une fois en place, j'ai surveillé les logs à la recherche d'éventuel traffic
bloqué alors qu'il devrait être autorisé. Cela m'a permis de découvrir 
quelques légers problèmes qui ont été résolus très rapidement en modifiant
les règles de filtrage ou de NAT correspondantes. La migration s'est donc 
effectuée en douceur puisque le routeur a été remplacé à 7h30, les accés 
Internet, les communications internes et les VPNs ainsi que la DMZ ont 
fonctionnés immédiatement. Les problèmes apparus au cours de la matinée ont 
tous été résolus en quelques minutes.

